Bug Description

This bug affects clusters in non-TLS setups that use a DNS endpoint storing multiple addresses, such as the cluster discovery endpoint in ElastiCache/MemoryDB.

Issue

When expanding a DNS endpoint from the initial nodes, we store the socket_address received from the expansion. However, in non-TCP connections, we haven't used the received socket_address. Instead, we re-resolved the original DNS entry when creating the actual connection. This caused a faulty mapping between the node address and the actual connection.

Example Scenario

Consider the endpoint cluster.dns.endpoint expanded to IP1, IP2, and IP3. Previously, all nodes were mapped to a connection with the first address resolved from cluster.dns.endpoint. If a DNS lookup for cluster.dns.endpoint returns the order [IP1, IP2, IP3], the connection map would be:

• IP1 -> connection to IP1
• IP2 -> connection to IP1
• IP3 -> connection to IP1

As a result, requests routed to IP2 and IP3 were actually sent to IP1, leading to MOVED errors.

Fix

This fix modifies the connect_simple function to use the provided socket_address, if available, ensuring that connections are made to the addresses used as keys in the connection map. This adjustment aligns the non-TCP connection behavior with that of the TcpTls connection.

Follow-Up

We should mock a DNS entry or the dnslookup function and add relevant tests to validate this fix.